Skip to content

feat: resolve project-id and org-id using instance-id#38

Open
LucDeCaf wants to merge 6 commits into
mainfrom
feat/optional-id-params
Open

feat: resolve project-id and org-id using instance-id#38
LucDeCaf wants to merge 6 commits into
mainfrom
feat/optional-id-params

Conversation

@LucDeCaf
Copy link
Copy Markdown

@LucDeCaf LucDeCaf commented Apr 14, 2026

Replaces #37 using a cleaner and (hopefully) simpler approach.


Using a newly introduced path in @powersync/management-client, automatically fetch the project_id and org_id flags when given the instance_id for a number of commands (where it makes sense to do so).

Example

Before:

powersync pull instance --project-id='project-123-456-789' --instance-id='instance-123-456-789'

After:

# Project ID is fetched from the management service if required
powersync pull instance --instance-id='instance-123-456-789'

Comment thread cli/src/api/cloud/validate-cloud-link-config.ts Outdated
Comment thread packages/cli-core/src/utils/resolve-cloud-instance-link.ts Outdated
Comment thread cli/src/api/cloud/validate-cloud-link-config.ts Outdated
@LucDeCaf LucDeCaf marked this pull request as ready for review May 25, 2026 11:29
Copy link
Copy Markdown
Collaborator

@stevensJourney stevensJourney left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it's going in a good direction. I'm happy with the implementation so far.

I left a few minor comments on some lines which stood out.

I think the main outstanding item currently is that of docs: both externally in our powersync-docs site (and agent skills) and here in the various README and docs files. We should update all references to commands which no longer need to supply the org/project IDs.

For commands where it's possible, I think we should steer people away from using the org/project IDs. If we removed the flags, that would be a breaking change as previous command invocations would fail - I'm not sure if there is an easy way to have the field be accepted, but be ignored. At the very last, I think we could mark those fields as deprecated.
It could be that carrying those fields makes things more confusing than just removing them, in which case it could be justified to make a breaking change and remove them.


export type ResolveCloudInstanceLinkInput = {
client: PowerSyncManagementClient;
instanceId?: string;
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: this should probably be required.

'org-id': Flags.string({
description:
'Organization ID (optional). Defaults to the token’s single org when only one is available; pass explicitly if the token has multiple orgs.',
description: 'Organization ID (optional). Resolved from the Cloud instance when omitted.',
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might make sense to deprecate these fields (and in SharedInstanceCommand).
We'd need to check how that gets displayed in the various command help sections. Ideally, users won't input this value for many commands anymore.

@benitav
Copy link
Copy Markdown

benitav commented May 25, 2026

I think we should steer people away from using the org/project IDs. If we removed the flags, that would be a breaking change as previous command invocations would fail - I'm not sure if there is an easy way to have the field be accepted, but be ignored.

Agreed, ideally they can just be ignored

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants